The use of telephones for communications purposes is commonplace and often taken for granted. If someone wants to talk to another person on the other side of the country, he or she can pick up a telephone and dial the person's phone number. A ringing noise is heard and normally, the called party answers the phone. Presently, in most cases, the ensuing cross-country conversation is carried over the Public Switched Telephone Network (PSTN). The PSTN has been upgraded on a nearly continuous basis as advances in technology have made improvements possible. For example, fiber optic lines have replaced the use of copper lines in many parts of the PSTN. In addition, digital telephone switches have replaced older analog telephone switches.
While significant changes have been made to the PSTN over the years, to the end user, i.e., customer, these changes have been relatively transparent. In most cases, end users have been allowed to keep their existing telephone numbers and receive their existing telephone services despite network changes resulting from network upgrades. As known in the art, the PSTN uses a Time Division Multiplexing (TDM) based network.
Telephone service providers are currently confronting the possibility of a transition from the current TDM based network to IP packet based networks which are likely to carry voice calls in the future. Unless significant steps are made to smooth the transition to a telephone system based on VOIP, this transition represents a dramatic development that has the potential for presenting customers with noticeable changes in their telephone services, including telephone number changes.
As technology evolves once again and the prospect of moving from a Time Division Multiplexing (TDM) based network to a Voice over IP ((VOIP)) based network becomes more of a reality, several major issues arise.
From a technical standpoint, e.g., from a telephone switch deployment and operational perspective, there is the issue of how to move calls and users from the PSTN to the VOIP network and back, as may be required.
In addition to the issues of physical implementation, there is the practical issue of how to make the transition to a VOIP telephone system as transparent as possible to telephone users. For example, it is highly desirable that phone numbers should not change, and preferably the telephone services that a customer currently receives should continue to function. Maintaining existing phone numbers is particularly important to large companies who want to keep their phone numbers for business purposes. In addition, services such as call forwarding, call waiting, voice mail, etc. are used by many end users, and an interruption in these billable services would be an inconvenience, and may hurt the telephone company from both a customer satisfaction and revenue standpoint.
Companies, even more so than individuals, tend to be risk adverse when it comes to implementing new technology. For this reason, large companies who use multiple phone lines, will probably want to migrate to a VOIP network gradually, e.g., a few lines at a time. This is likely to be the case at least until the (VOIP) technology has been proven to be reliable. For example, if a company has 100 telephone lines it may only want to convert 25 of those lines into VOIP network telephone lines, in order to test the new technology without potentially losing all communications. In addition, before committing to switching lines to the (VOIP) telephone network, a company may want assurances that it will be able to switch the telephone lines back to the existing PSTN on short notice in the event that difficulties are encountered with the VOIP service.
A gradual transition of the type likely to occur presents hardware deployment challenges to telephone companies. Telephone companies may wish to provide VOIP telephone service for a small number of lines serviced by an existing switch, e.g., 25 lines out of a company's 100 lines, without having to make hardware upgrades to, or replace, the telephone switch which directly services the company's office. Given the cost of upgrading switches, it may only be justifiable from a cost standpoint, to upgrade an otherwise functional telephone switch, when a large number of subscribers or telephone lines serviced by the switch are ready to be transferred to VOIP service. Unfortunately, it is unlikely that a large number of users will agree to switch to a relatively new and somewhat unproven technology all at once.
In order to provide enhanced telephone services, many telephone companies now support, as part of the PSTN, Advanced Intelligent Network (AIN) functionality. AIN capabilities have made it easier to provide a wide array of previously unavailable telephone services. In an AIN system, telephone central offices each include one or more switches, each of which serves as a signal switching point (SSP).
Each SSP can detect one of a number of call processing events called AIN “triggers” or events. One such trigger is a Specific Digit String (SDS) trigger.
This trigger is activated based on exact matches in the digits of a phone number, with a corresponding set of trigger digits. For example, if an SSP has an SDS six digit trigger set to 123-456, then any call passing through the switch directed to a phone number starting with 123-456 will activate that trigger. A local number portability (LNP) trigger is a type of trigger that will also be activated in response to a specific set of digits in a call matching a set of digits set as part of the LNP trigger.
When an AIN trigger is activated at an SSP because of the occurrence of a trigger event, the SSP suspends processing of the call that activated the trigger and generates a call processing message, e.g., a TCAP message, used to obtain call processing instructions from a service control point (SCP). The SSP forwards the call processing message, e.g., via a common channel interoffice signaling (CCIS) link utilizing the Signal System 7(SS7) protocol, to a Service Control Point (SCP). The SCP determines the appropriate call processing instruction(s) to be sent from the switch based on software instructions and, in many cases, call specific information received from the switch. The call specific information may include, e.g., the calling party telephone number, the called party telephone number and one or more additional numbers or fields included in the call processing message received by the SCP which are available from a call transmitted in accordance with the SS7 standard.
The SCP may be implemented as an integrated service control point (ISCP). ISCPs normally include service creation logic and other functionality sometimes omitted from standard SCPs. If needed, the SCP can instruct the SSP at which the AIN trigger was activated to obtain and forward additional information, e.g., information relating to the call.
In response to a call processing message, the SCP accesses one or more stored call processing information or records (CPRs) to generate from the data received from the SSP one or more control messages. The call control messages are used to instruct the SSP on how to process the call that activated the AIN trigger. As part of a call control message, an ISCP can instruct the SSP to complete, e.g., forward the call, to a destination number provided by the SSP. Thus, an SCP can redirect a call in response to activation of an AIN trigger.
The SCP also has the ability to send the call to an outside resource, such as an intelligent peripheral using a send to outside resource (STOR) instruction. Intelligent peripherals are frequently coupled to SSPs to provide message announcement capabilities, voice recognition capabilities and other functionality which is not normally provided by the SSP.
In response to control messages, the SSP completes the phone call to which the control message relates as instructed by the control message.
In order to be allowed to compete in both he local and long distance telephone markets, some providers of local telephone service have had to open up the markets in which they provide local telephone service to competition. This often involves providing a mechanism by which a competitor's telephone switch can be used to provide local call routing and billing operations despite the fact that the customer's telephone line is not directly connected to the competitor's switch.
Some telephone service providers use AIN functionality and in particular, the AIN Local Number Portability (LNP), to enable a competitor's telephone switch to provide local telephone service despite the fact that the competitor's switch is not directly coupled to the end user's customer premise.
AIN LNP triggers are activated by calls originating from, or directed to a telephone number or portion thereof, are set at SSPs. Normally, the first six digits of telephone numbers that have been ported to another physical location activate the LNP trigger in an SSP.
Once an LNP trigger is activated at an SSP, the SSP pauses the call that activated the trigger, and sends a call processing message to an SCP. The SCP accesses a LNP database that includes information associating ported telephone numbers to Location Routing Numbers (LRNs). Each LRN normally corresponds to a telephone switch, e.g., a competitor's switch, which is responsible for servicing one or more ported calls. Accordingly, the LRN is the number that identifies the SSP to which the called telephone number is ported. While one LRN is associated with each ported telephone number, normally, several ported telephone numbers are associated with the same LRN.
In response to an LNP trigger being activated the SCP obtains from an LNP database the LRN corresponding to the ported number which activated the LNP trigger. The retrieved LRN is placed in the called party field, and the actual called telephone number is placed in a spare field of a call completion message sent by the SCP to the SSP. This call processing data is returned to the SSP, where call processing is resumed. The SSP looks in the called party field and routes the call to the SSP identified by the LRN in the called party field, i.e., the SSP to which the telephone number was ported.
When an SSP receives a call directed to its LRN it extracts the actual called party number from the spare field and then proceeds to process the call using the extracted called party number. In this manner, using the actual telephone number, the call is completed to the called party by the second, e.g., competitors, SSP. This is not correct.
From the above discussion, it is clear that AIN functionality has been used to provide a wide range of services such as call forwarding and call screening. It has even been used to support competition between local telephone service providers. The transition to VOIP is particularly challenging since such functionality may not fully exist in VOIP networks.
In view of the above discussion, it is apparent that there is a need for methods of effectively moving voice and/or data from a PSTN environment to and from a (VOIP) environment. It is desirable that these methods be transparent or relatively transparent to the end user, e.g., customers should be able to receive their current telephone services regardless of being moved to or from a (VOIP) environment. In addition, the method should allow for gradual transition from the PSTN to a VOIP network.